`TRUSTED_PROVIDER_DOMAINS` on the frontend was redundant with the
backend's canary allowlist (`ALLOWED_DISCOVERY_DOMAINS`):

- A domain can only reach `discoverSsoConfig` after
  `add_discoverable_oidc_config` succeeded on the backend, which traps
  for domains not on the admin-vetted canary list.
- Once we've agreed that `dfinity.org` is trustworthy, whatever they
  publish at `/.well-known/ii-openid-configuration` represents their
  IdP choice — the org knows their own provider better than II does.
- An attacker who can tamper with a trusted domain's `.well-known`
  has already broken something more fundamental than the second-hop
  allowlist would protect against.

Removed `TRUSTED_PROVIDER_DOMAINS` and the matching check in
`validateProviderUrl`. Retained checks that still carry their weight:

- HTTPS on every URL in the chain.
- Issuer hostname / authorization_endpoint hostname must match the
  `openid_configuration` hostname (prevents a tampered provider-
  discovery doc from bouncing auth off-host after we've committed to
  a provider).
- Domain format validation on user input.

Updated the module docstring to spell out where the first-hop trust
actually comes from, and dropped the now-obsolete
"rejects untrusted provider domains" test.

Also means per-org onboarding no longer needs an II frontend deploy —
a new SSO org just needs the admin call to `add_discoverable_oidc_config`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Frontend error mapping in SignInWithSso now distinguishes each distinct
failure mode of the two-hop chain and includes the underlying detail
where it is actionable:

- HTTP-error from hop 1 → "X didn't serve /.well-known/...-configuration
  (HTTP 404). The domain owner needs to publish it for II to sign you
  in."
- Network failure from hop 1 → "Couldn't reach X. Check the spelling
  and your network, then try again."
- Malformed hop-1 response → includes the zod error detail (e.g.
  "expected string, received undefined at client_id") or the HTTPS
  check message.
- Hop-2 hostname mismatches (issuer / auth endpoint) → short human
  summary + the raw message for context.
- Canary-allowlist trap → "Ask an II admin to register this domain."
- Rate-limit / concurrency errors → friendly paraphrase.

`DomainNotConfiguredError.detail` is now a public field so the UI can
read the inner error text instead of collapsing to "invalid response".

---

Also temporarily adds `s4i6f-riaaa-aaaad-agnna-cai.icp0.io` to
`ALLOWED_DISCOVERY_DOMAINS` alongside `dfinity.org`, so the two-hop
flow can be exercised end-to-end from a test canister on staging-C.

DO NOT MERGE: the test entry must be removed before this PR lands on
main. The production canary allowlist stays at just `dfinity.org`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

An SSO-linked access method (e.g. via `dfinity.org`'s Okta) was being
rendered as "Google account" with the Google logo because
`findConfig(iss, metadata)` matched on issuer alone. When the
underlying IdP happens to be Google, the credential's `iss` is the
Google issuer and collides with the direct "Sign in with Google"
entry in `openid_configs` — even though the `aud` (client_id) is
completely different.

Changes:

- `findConfig(iss, aud, metadata)` now matches on both `iss` and `aud`
  (the OAuth client_id). `aud` is accepted as `string | undefined`;
  callers that haven't been extended to track `aud` yet
  (`LastUsedIdentity`-based paths — see dfinity#3795) keep their issuer-only
  behavior for now, which is correct for direct providers and
  mis-attributes SSO credentials at those legacy sites only.

- `openIdName(iss, sub, aud, metadata)` now also consults a per-device
  localStorage map (`ssoDomainStorage.ts`) populated at SSO link time.
  If the credential was linked via SSO on this device, the label
  becomes the `discovery_domain` the user typed (e.g. "dfinity.org
  account").

- `openIdLogo(iss, aud, metadata)` returns `undefined` for credentials
  that don't match any direct provider — the access-methods UI uses
  the generic SSO key icon as a fallback in that case.

- `SsoDiscoveryResult` grows a `domain` field; both sign-in and
  add-access-method flows persist the `(iss, sub, aud) → domain`
  mapping after a successful SSO link, so the next render shows the
  correct label.

- `OpenIdItem` renders the `<SsoIcon>` when `openIdLogo` returns
  undefined, and falls back to the literal "SSO" word when no domain
  is stored (cross-device case).

Cross-device labelling (credential linked on device A, viewed on
device B) remains wrong until the `discovery_domain` is persisted on
the backend credential — tracked in dfinity#3795.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`openid_credential_add` rejects with `OpenIdCredentialAlreadyRegistered`
for both the case where the `(iss, sub, aud)` is attached to THIS
identity and the case where it's on a DIFFERENT one. The UI used the
generic "already linked to another identity" toast for both, which is
misleading when the credential is in fact already on the identity the
user is managing.

Distinguish the two on the client:

- `addAccessMethodFlow.linkOpenIdAccount` now catches the
  `OpenIdCredentialAlreadyRegistered` error, queries `get_anchor_info`
  for the current identity, and checks whether `(iss, sub, aud)` is
  already in `openid_credentials`.
- If yes, rethrow as the new `OpenIdCredentialAlreadyLinkedHereError`
  (plain JS Error, not a canister error).
- If no, re-throw the original canister error so it hits the existing
  "another identity" handler unchanged.

`error.ts` gains a matching branch that shows "This account is already
linked to this identity" for the new class; the original message is
preserved for the truly-different-identity case.

Covers both `linkOpenIdAccount` and `linkSsoAccount` since the latter
delegates to the former.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The direct-OpenID resume path in `authorize/+page.svelte` still called
`findConfig(iss, metadata)` — the legacy 2-arg signature. After
`findConfig` was updated to `(iss, aud, metadata)` for the SSO
credential-disambiguation change, this call stopped compiling (svelte-
check flagged "Expected 3 arguments, but got 2").

Destructure `aud` out of `decodeJWT(jwt)` and pass it through so the
strict-then-fallback resolution runs the same way as everywhere else.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The earlier `chore(fe): sync auto-extracted locale catalogs` commit
picked up the new "Checking..." / "Sign In With SSO" / "Company domain"
msgids, but also cleared the existing translations of "Choose method
to continue" in 10 non-English catalogs. That msgid is still used by
`/+page.svelte`, so the regression would have fallen back to English
at runtime.

Restore the prior translations from `origin/main` for de, es, fr, id,
it, nl, pl, ru, uk, ur.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- ssoDiscovery.ts header: drop the stale claim that callers must
  independently check the domain against a backend list. The actual
  gating is `add_discoverable_oidc_config` trapping on the canary
  allowlist before `discoverSsoConfig` runs — state that directly.
- PickAuthenticationMethod.svelte: the comment next to the SSO entry
  still claimed the SignInWithSso screen would reject every input with
  "This domain is not registered…", but rejection lives on the canister
  now. Describe the real behavior.
- SignInWithSso.svelte: the submit `<Button>` had both `type="submit"`
  and `onclick={handleSubmit}` while the surrounding `<form>` also
  calls `handleSubmit` in `onsubmit`. Clicking the button fired the
  handler twice. Drop the onclick — the form's onsubmit covers both
  Enter-in-input and button-click, and it still runs synchronously
  from the trusted user gesture (critical for the Safari popup).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The SSO canary allowlist used to be a single const with both the real
prod domain (`dfinity.org`) and a staging test canister host wearing a
`DO NOT MERGE` sticker. Replace the const with
`allowed_discovery_domains()`, which reads `is_production` from the
persistent state and branches:

- `is_production == Some(true)` (id.ai)       → `dfinity.org`
- otherwise (beta.id.ai, staging, local, CI)  → `beta.dfinity.org`

Keeping the two disjoint means a DNS takeover of the beta test domain
can't backdoor the production canister, and it lets us stage new IdP
registrations on beta without touching the production issuer. Also
removes the `DO NOT MERGE` staging-C entry the earlier commit carried.

Tests:
- `should_add_oidc_config_via_update_call`, `should_coexist_with_
  openid_configs`, `should_deduplicate_oidc_configs` switched to the
  default (non-prod) install and the beta domain.
- `should_reject_disallowed_discovery_domain` extended to assert that
  the production domain is rejected on a non-prod canister.
- New `should_allow_only_production_domain_on_production_canister`
  installs with `is_production: Some(true)` and asserts that only
  `dfinity.org` is accepted.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…received"

When a user tries to sign in via SSO and the provider's OAuth app is
misconfigured — most often the Okta/Auth0/etc. app is set to
`response_types=[code]` only, and refuses our `response_type=id_token
code` hybrid request — the provider redirects back to II's callback
with something like:

  #state=…&error=unsupported_response_type
    &error_description=The+response+type+is+not+supported…

`requestWithPopup` used to just check for `id_token`, find it missing,
and throw `Error("No token received")`. That looks exactly like a bug
in II, sending admins down the wrong rabbit hole — the real fix is a
knob in the SSO app.

Changes:
- New `OAuthProviderError` in `openID.ts` carrying `error` +
  `errorDescription` separately (RFC 6749 §4.1.2.1 / 4.2.2.1 fields).
- New `extractIdTokenFromCallback(callback, expectedState)` helper:
  single source of truth for how we interpret a callback URL fragment,
  and the unit-testable seam. It throws `OAuthProviderError` BEFORE
  the `id_token` null-check, so a provider-side failure wins over the
  generic fallback. `requestWithPopup` now delegates to it.
- `SignInWithSso.svelte#mapSubmitError` specializes
  `unsupported_response_type` and `access_denied`, and otherwise falls
  back to `{error}: {error_description}` — all interpolated with the
  typed domain so the user knows which SSO they're debugging.
- `handleError` in `error.ts` handles `OAuthProviderError` for callers
  that route through the generic error sink (direct-OpenID entry
  points, not just SSO).

Tests:
- 6 new unit tests for `extractIdTokenFromCallback`: success, provider
  error with and without description, state mismatch (including a
  "forged-error" CSRF-shaped case where state is checked before error
  so an attacker can't drive the UI via a crafted fragment), missing
  state, and the "neither id_token nor error" fallback.
- 3 new unit tests for `OAuthProviderError`: message with/without
  description, and `instanceof Error` (so existing catch blocks still
  see it).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>